Received: from umd5.umd.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA10130; Mon, 25 Apr 1994 11:59:36 -0400
Received: from mcs.umes.umd.edu (umescsnw1.umd.edu [131.118.127.2]) by umd5.umd.edu(8.6.4/94Jan25)
with SMTP id LAA27082; Mon, 25 Apr 1994 11:59:20 -0400
Received: from UMESCSNW1/MAILQUEUE by mcs.umes.umd.edu (Mercury 1.11);
Mon, 25 Apr 94 12:00:41 EDT
Received: from MAILQUEUE by UMESCSNW1 (Mercury 1.11); Mon, 25 Apr 94 12:00:01 EDT
To: winsock-hackers@sunsite.unc.edu
From: "James M. O'Brien, Jr" <jobrien@mcs.umes.umd.edu>
Organization: University of MD Eastern Shore
Date: Mon, 25 Apr 1994 11:59:56 EDT
Subject: FD_READ @ recv()
Reply-To: jobrien@diver.umd.edu
Priority: normal
X-Mailer: WinPMail v1.0 (R2)
Message-Id: <26C62214D48@mcs.umes.umd.edu>
I've been working with WSAAsyncSelect and FD_READ. Attempting
to make wsfinger an async client. I've been able to do this but I've
found one glitch I am not sure that either I am handling correclt or its
not completely obvious to me.
As an example:
Once I've connected, I use WSAAsyncSelect to set the socket to NB
and I want FD_READ....
In the wndproc I handle FD_READ and call recv() once for each
FD_READ received. Where it appears to become grey, how does one
handle the end of a data stream? As in receiving a reply from a finger
server, its not readily apparent, how one would recognize that the
stream is EOF.
What I've done so far is to test on bytes read using the following:
case WM_WINSOCK :
switch (WSAGETSELECTEVENT(lParam)) {
case FD_READ :
// Read Socket Data and Write it out
if (ReadSocket(hMainEdit) == 0) {
closesocket(sSocket);
bCmdInProgress = FALSE;
SendMessage(hWndMain,WM_SETCURSOR,hWndMain,0L);
return 0;
}
....
Now this appears to work fine using Novell's TCP/IP & their
winsock.dll. But it doesn't work correctly over Trumpet's winsock.
I'll have to re-read the finger rfc, but I don't recall any explicit end of
stream markers.. How would one handle this situation?
Thanks
- Jim O.
From paul@atlas.dev.abccomp.oz.au Wed Apr 27 09:25:31 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA19750; Wed, 27 Apr 1994 00:12:10 -0400
Received: by usage.csd.unsw.OZ.AU id AA11938
(5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 27 Apr 1994 14:11:59 +1000
Received: by atlas (4.1/1.35)
id AA15057; Wed, 27 Apr 94 14:25:32 EST
Message-Id: <9404270425.AA15057@atlas>
From: paul@atlas.abccomp.oz.au
Date: Wed, 27 Apr 1994 14:25:31 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: mmthomas@hpccoa.corp.hp.com,
Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
Subject: Re: Unix to Winsock select()
Thus expounded Markham Thomas on Apr 26, 6:22pm:
/--------------------
| I have a problem with porting sockets code from an HP
| 3000 and 9000 to the Winsock platform. In particular the problem
| occurs on the select() statement.
| The unix man pages for HP show the following as the definition
| for the second parameter to select: (readfs is the variable)
|
| (option1) struct fd_set readmask, readfds;
|
| (option2) int readmask = 0;
| int readfs;
|
| The HP systems will take either an int or a fd_set structure pointer as the
|parameter. You would use the structure if the integer bit mask can't
|hold the number of sockets you want to test.
| The problem is that I wanted to have the same code (or prevent a major
| rewrite) as that on the HP systems. It appears that the winsock.h header
| file desires the structure pointer at the parm, and won't support an int.
That's correct - the Winsock select() function only operates on an
fd_set structure, because for Winsock an fd_set is implemented differently
than in unix.
In Winsock, an 'fd_set' is an array of sockets, with each
one holding a possible socket handle, wheras in Unix the fd_set is a
collection of integers constructing a bitmask, with each bit associated with
a socket. This change had to be made because in Windows Sockets, the
value of a 'socket' handle could be any possible value (except 0xFFFF),
while under unix a 'socket handle' is a small integer (4,5,6 etc).
The FD_SET, FD_CLR macros are also re-written so that, as long as your
code uese these, the different underlying structure of the fd_set is
transparent to the application.
I still can't see your problem - code for the fd_set case at all times,
and ignore the fact that HP unix will, in some cases, allow you to use
an integer instead of an fd_set.
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
From paul@atlas.dev.abccomp.oz.au Wed Apr 27 09:53:14 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA23736; Wed, 27 Apr 1994 00:40:45 -0400
Received: by usage.csd.unsw.OZ.AU id AA13120
(5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 27 Apr 1994 14:39:47 +1000
Received: by atlas (4.1/1.35)
id AA15173; Wed, 27 Apr 94 14:53:15 EST
Message-Id: <9404270453.AA15173@atlas>
From: paul@atlas.abccomp.oz.au
Date: Wed, 27 Apr 1994 14:53:14 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: FisherM@is3.indy.tce.com,
Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
Subject: RE: DNS interface
Thus expounded Fisher Mark on Apr 26, 6:46pm:
/--------------------
|
|To quote paul@atlas.abccomp.oz.au (">") and pbh@MIT.EDU ("|>"):
|>|Most vendors already have res_mkquery() or the equivalent in their stacks
|>|because it is used by the DNS support. Why don't we just make sure this
|API
|>|is exposed in the next release of the spec?
|>
|>Oh dear. Our internals don't use anything resembling res_mkquery() - can we
|>take a straw-poll - which stacks _do_ have a res_mkquery(), whether
|>accessable from outside the DLL or not, and which stacks don't?
|
|Furthermore (to betray my ignorance :)) is the DNS interface defined in an
|RFC, or do you have to look at example code to figure it out? I have the
|example code -- I'm just curious...
There is no RFC that standardises the API for DNS, just as there is no
RFC standardising an API for TCP/IP in general (these is no 'BSD sockets"
RFC) - most people have copied the interface adopted by Unix popularised
by BSD, known as "BSD Sockets", although many are moving to
an alternative API called "TLI" - Transport Level Interface. The same,
I guess, for the interface to DNS (which was added much later than the
original 'BSD sockets' interface was codified), which for BSD was added
because the original name resolution routines (gethostbyname etc) were
designed for reading database files, not for dynamic server queries, and
couldn't handle more generic DNS-specific queries like 'which server
handles domain YYY' and 'who is in charge of the DNS for domain XXX'.
|I do like the idea of a standard DLL for this.
So do I - much more than forcing each vendor to implement a rarely
used function like res_mkquery(), which is very DNS-specific. Not every
stack, and I would guess in fact that very few stacks, actually implement
their gethostbyYYY() calls as generic calls as an internal call to
a 'res_mkquery' routine - certainly we manage quite well without one.
The correct solution for a more generic DNS interface would be a DLL (that
may well implement 'res_mkquery()') that creates the appropriate UDP
datagrams and sockets, and does the query utilising the base SOCK_DGRAM
capability of the generic Windows Sockets stack underneath. Then the
single DLL could be used by everybody on top of everybody's stack, and
only one person needs to invent the wheel.
Cheers,
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
From paul@atlas.dev.abccomp.oz.au Wed Apr 27 09:57:06 1994
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA24186; Wed, 27 Apr 1994 00:43:33 -0400
Received: by usage.csd.unsw.OZ.AU id AA13244
(5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 27 Apr 1994 14:43:40 +1000
Received: by atlas (4.1/1.35)
id AA15202; Wed, 27 Apr 94 14:57:07 EST
Message-Id: <9404270457.AA15202@atlas>
From: paul@atlas.abccomp.oz.au
Date: Wed, 27 Apr 1994 14:57:06 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: paul@atlas.abccomp.oz.au,
Multiple recipients of list <winsock-hackers@sunsite.unc.edu>
Subject: Re: FW: What's happening here?
Thus expounded paul@atlas on Apr 26, 6:32pm:
/--------------------
|
|Assuming port 1111 is the server port, and 1026 is your Winsock's port,
|this looks like a TCP bug. In the second line (the first 1026->1111 packet)
|the ACK field should be set to the previous SEQ field+1. Because its not,
|the remote machine is aborting the connection and returning a RST.
etc.
Anyone know which 'white hole' this message came from? I dimly
remember sending this many months ago, and don't remember if it was
seen on the list back then, but it certainly aint recent!
Wierd.
--
Paul Brooks |paul@abccomp.oz.au |Emerging Standard:
TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet
579 Harris St., Ultimo | | been superseded.
Sydney Australia 2007 |ph: +61 2 281 3155 |
From meunier@capsogeti.fr Wed Apr 27 10:50:03 1994
Received: from Relay1.OLEANE.NET by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA07478; Wed, 27 Apr 1994 02:51:58 -0400
Received: from csinn (csinn.cgs.fr [194.2.88.135]) by relay1.oleane.net (8.6.5/8.6.5) with SMTP id IAA22451 for <winsock-hackers@sunsite.unc.edu>; Wed, 27 Apr 1994 08:51:54 +0200
X-Authentication-Warning: relay1.oleane.net: Host csinn.cgs.fr claimed to be csinn
